Skip to content

fix(app): recover from a silently dead event stream - #39349

Open
Luppa90 wants to merge 1 commit into
anomalyco:devfrom
Luppa90:fix-event-stream-stall
Open

fix(app): recover from a silently dead event stream#39349
Luppa90 wants to merge 1 commit into
anomalyco:devfrom
Luppa90:fix-event-stream-stall

Conversation

@Luppa90

@Luppa90 Luppa90 commented Jul 28, 2026

Copy link
Copy Markdown

Issue for this PR

Closes #39352

Type of change

  • Bug fix
  • New feature
  • Refactor / code improvement
  • Documentation

What does this PR do?

Fixes the web UI freezing mid-session: the spinner keeps spinning, the timeline stops, and only a page refresh reveals the run finished long ago.

Two defects compound.

A dead event stream is undetectable. The SSE consumer reads the response body with no timeout, so a socket that dies without a FIN/RST parks reader.read() forever — no error is thrown, so the reconnect loop in server-sdk.tsx is never re-entered. Heartbeats can't help, because v2 sends them as SSE comment frames, which the parser discards without yielding an event, leaving liveness invisible at the event level. So this tracks the stream at the byte level (comment frames included) via a fetch wrapper, and a per-attempt watchdog aborts after 45s of silence — 3 missed heartbeats — dropping into the existing reconnect path. The watchdog aborts a controller captured per attempt, so a stale timer can't kill a healthy successor connection.

Reconnecting alone repairs nothing. session_status is written only by session.execution.* events, so a run that finishes during the outage stays busy forever, and the active-sessions refetch was gated on the query having no data — meaning it only ever fired on the first connect. Now every reconnect refetches and reconciles against the server.

The reload set is keyed off sessions that currently hold messages, not off status. That is deliberate: bootstrapDirectory also rewrites session_status from the server on reconnect and then calls resolve(), which refreshes session info but never messages. When that lands first, a finished session already reads idle, so a status-keyed reload skips it — clearing the spinner while leaving the timeline frozen mid-message. Keying off locally-held messages is immune to that ordering. Sessions in retry keep their status, since retries run inside the execution fiber and the server still reports them active on both protocols.

How did you verify your code works?

  • Ran patched and unpatched builds side by side against real workloads. The unpatched UI froze repeatedly. The first patched build fixed the detection and the stuck spinner but still left a frozen timeline in one tab — that was the bootstrap race described above, caught in live use and fixed here. The console showed the watchdog firing once (idle: 45038) and reconnecting cleanly, which confirmed detection was working and the repair was not.
  • Unit tests: byte tracking includes heartbeat frames; non-stream fetches pass through untouched; statuses for finished runs are cleared; retry statuses preserved; sessions holding messages are reloaded; and, as a regression test for the race, a finished session whose status a concurrent bootstrap already reset still gets reloaded. That last test was checked against the pre-fix implementation to confirm it actually fails there.
  • All 9 transport e2e specs pass (session-timeline-transport.spec.ts, remote-tab-busy.spec.ts), including reconnect-after-close, reconnect-after-error, and heartbeat delivery.
  • bun test for the app package, typecheck, prettier and oxlint are clean. The only failing test is the pre-existing ar i18n parity gap, which fails identically on dev.

Screenshots / recordings

Not a visual change — the fix is that the timeline and spinner recover on their own after a dead connection, instead of freezing until a manual refresh.

Checklist

  • I have tested my changes locally
  • I have not included unrelated changes in this PR

@github-actions github-actions Bot added needs:compliance This means the issue will auto-close after 2 hours. needs:issue labels Jul 28, 2026
@github-actions

Copy link
Copy Markdown
Contributor

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

  1. Open an issue describing the bug/feature (if one doesn't exist)
  2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

@github-actions github-actions Bot removed needs:issue needs:compliance This means the issue will auto-close after 2 hours. labels Jul 28, 2026
@github-actions

Copy link
Copy Markdown
Contributor

Thanks for updating your PR! It now meets our contributing guidelines. 👍

The SSE read has no timeout, so a socket that dies without a FIN or RST
leaves the consumer parked forever: no error is thrown, the reconnect loop
is never re-entered, and the UI freezes mid-message while the run continues
server-side. Heartbeats did not help because the v2 server sends them as SSE
comment frames, which the parser discards without yielding an event, so
liveness was invisible to the app.

Track liveness at the byte level instead and abort an attempt after 45s of
silence, dropping into the existing reconnect path.

Reconnecting alone was not enough. Session status is driven purely by
session.execution.* events, so a run that finished during the outage stayed
busy forever, and the only resync hook fired solely on the first connect
because it was gated on the active-sessions query being unfetched. Reconcile
against the server on every reconnect: clear status for runs that are no
longer active and reload the timelines held locally.

Reload by what is held locally rather than by status. A directory bootstrap
also rewrites session_status from the server on reconnect, and when it lands
first a finished session already reads idle, so keying the reload off status
would clear the spinner while leaving the timeline frozen mid-message.
@Luppa90
Luppa90 force-pushed the fix-event-stream-stall branch from b9a3cfb to 31d07d4 Compare July 28, 2026 20:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Web UI freezes mid-session when the event stream dies silently; only a page refresh recovers

1 participant